The way this is implemented makes lines pretty jittery when the depth prepass is enabled:

This is not an issue when the depth prepass is disabled or when using the wireframe debug draw mode, as both make all geometry see-through.

We should have a polygon offset for wireframe lines (similar to glPolygonOffset() in OpenGL), as mentioned in godotengine/godot-proposals#1000.

The way this is implemented makes lines pretty jittery when the depth prepass is enabled.

This is not an issue when the depth prepass is disabled or when using the wireframe debug draw mode, as both make all geometry see-through.

We should have a polygon offset for wireframe lines (similar to glPolygonOffset() in OpenGL), as mentioned in godotengine/godot-proposals#1000.

One possible workaround for this would be to set debug/rendering/force_wireframe twice as wide to compensate for half of it clipping into the original geometry. On my machine, line widths other than 1 lack MSAA support, but TAA is able to compensate for this.

I'm having second thoughts about this approach. Viewport::DEBUG_DRAW_WIREFRAME already exists, so debug/rendering/force_wireframe just ends up introducing redundant functionality. It would be better to have some way to force enable any of the Viewport::DEBUG_DRAW_* options at runtime, which would also allow the hypothetical outline mode to be seamlessly supported if it's ever added.

I'll leave this PR open for now though, in case anyone is interested in using it as a stopgap solution.

It would be better to have some way to force enable any of the Viewport::DEBUG_DRAW_* options at runtime, which would also allow the hypothetical outline mode to be seamlessly supported if it's ever added.

I agree with that too – it might also be worth having an option to synchronize the debug draw mode of the first 3D editor viewport with the running project, similar to camera replication.

Repurposing this as a rendering/driver/wireframe/width setting

Probably salvageable?